home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 26
/
Cream of the Crop 26.iso
/
bbs
/
setr180.zip
/
README.1ST
< prev
next >
Wrap
Text File
|
1997-06-07
|
7KB
|
118 lines
Read this file before using SETR's history reporting feature!!!
With the release of version 1.50, SETR has grown into a pretty complex
program. I have attempted to keep the docs short and to the point, but
there has been some confusion about the history reporting functions, so I
decided to add this explanation instead of adding to the docs. Hopefully
after reading this, and playing with SETR and the history functions for a
while, all you will need to refer to is the docs in the future.
First of all, when the history updating is activated by the /HU switch,
SETR will scan the log file as before, but it will then create three data
files to store the history information.
SQHIST.DTE This is the begin and end dates for the history files.
SQHIST.TAG This is the areatag data for the history reports.
SQHIST.ORG This is the origin address data for the history reports.
Each time SETR is run with the /HU switch, the traffic stats for the
current log file are appended to the existing history data files. The data
files are then sorted and consolidated producing updated history data
files. If the /HR switch has also been used, the history data files are
read in, and the History Report is generated. If you are only tracking a
single network, or just tracking all of your mail in one report, the
process is pretty simple and quick. All that needs to be explained is how
to setup your history reporting period.
On my system, I maintain a weekly history report, beginning on Sunday,
and ending at midnight Saturday. Therefore, my daily maintenance event
has the following SETR command in it:
SETR RPT=SQ-DAILY.RPT HST=SQWEEKLY /HU /HR /AP
The above command tells SETR to scan my SQUISH.LOG file, produce a daily
traffic report "SQ-DAILY.RPT", which is appended to each day, and create /
update SQWEEKLY.DTE, SQWEEKLY.TAG, SQWEEKLY.ORG, and SQWEEKLY.RPT. The
SQWEEKLY.RPT file is overwritten each night with the updated history
report.
On Saturday night / Sunday morning, I run the same command with /HK
added to the command line. That tells SETR to do everything the same,
except that after the history report, SQWEEKLY.RPT, is written, the history
data files are deleted. The SQ-DAILY.RPT, and SQWEEKLY.RPT files are
packed away in another part of the event, and the system is ready to begin
again on Sunday night.
The difference in the commands used above, and the default history
report settings, is that with the commands above, SETR created and updated
SQWEEKLY.DTE, SQWEEKLY.TAG, SQWEEKLY.ORG, and SQWEEKLY.RPT instead of the
SQHIST.* filenames that would be used if the HST=SQWEEKLY option had not
been used.
And this is where SETR can become a powerful reporting tool. If you
want to produce a consolidated traffic report, and a report for each of the
nets that you have on your system, all that you need to do is run SETR once
for each report that you want to create. Here is how I track my mail
traffic in more detail:
SETR RPT=FN-DAILY.RPT HST=FNWEEKLY /XFIDONET.XCL /HU /HR /AP
SETR RPT=IN-DAILY.RPT HST=INWEEKLY /XITCNET.XCL /HU /HR /AP
SETR RPT=NM-DAILY.RPT HST=NMWEEKLY /XNETMAIL.XCL /HU /HR /AP
SETR RPT=PN-DAILY.RPT HST=PNWEEKLY /XPWCNET.XCL /HU /HR /AP
SETR RPT=RN-DAILY.RPT HST=RNWEEKLY /XRGSNET.XCL /HU /HR /AP
SETR RPT=SQ-DAILY.RPT HST=SQWEEKLY /HU /HR /AP /KL
First I had to create five tag exclusion files in the directory named:
FIDONET.XCL, ITCNET.XCL, NETMAIL.XCL, PWCNET.XCL, and RGSNET.XCL. The
FIDONET.XCL file contains all of the areatags that do not come from
FidoNet, and the ITCNET.XCL file contains all of the areatags that do not
come from ITCNet, and so on. Those files are all identified by the /X
switch.
When this group of commands is executed, I get the following results:
NET DAILY RPT DATES HST AREATAG HST ORIGIN HST HISTORY RPT
FIDONET FN-DAILY.RPT FNWEEKLY.DTE FNWEEKLY.TAG FNWEEKLY.ORG FNWEEKLY.RPT
ITCNET IN-DAILY.RPT INWEEKLY.DTE INWEEKLY.TAG INWEEKLY.ORG INWEEKLY.RPT
NETMAIL NM-DAILY.RPT NMWEEKLY.DTE NMWEEKLY.TAG NMWEEKLY.ORG NMWEEKLY.RPT
PWCNET PN-DAILY.RPT PNWEEKLY.DTE PNWEEKLY.TAG PNWEEKLY.ORG PNWEEKLY.RPT
RGSNET RN-DAILY.RPT RNWEEKLY.DTE RNWEEKLY.TAG RNWEEKLY.ORG RNWEEKLY.RPT
SQUISH SQ-DAILY.RPT SQWEEKLY.DTE SQWEEKLY.TAG SQWEEKLY.ORG SQWEEKLY.RPT
Notice that the last command line does not contain a /X switch, because
it is the consolidated report, including all of the traffic thru the
system. Also, there is a /KL switch on the end of the last command line.
That tells SETR to delete the SQUISH.LOG file after all of the reports have
been processed. Once again, in my weekly event, which runs at midnight on
Saturdays, all of the above commands also have a /HK switch to delete the
history files after the history reports have been generated, thus making
the system ready for the next week's reports. That event also packs up and
moves all of the reports out of the reporting directory so they won't be in
the way.
The command lines below would create exactly the same files and reports,
but the tag exclusion files would have to be named: FNWEEKLY.XCL,
INWEEKLY.XCL, NMWEEKLY.XCL, PNWEEKLY.XCL, and RNWEEKLY.XCL instead of the
names used in the example above. The difference is the /Z switch, which
combines the HST= and /X arguments into a single argument:
SETR RPT=FN-DAILY.RPT /ZFNWEEKLY /HU /HR /AP
SETR RPT=IN-DAILY.RPT /ZINWEEKLY /HU /HR /AP
SETR RPT=NM-DAILY.RPT /ZNMWEEKLY /HU /HR /AP
SETR RPT=PN-DAILY.RPT /ZPNWEEKLY /HU /HR /AP
SETR RPT=RN-DAILY.RPT /ZRNWEEKLY /HU /HR /AP
SETR RPT=SQ-DAILY.RPT HST=SQWEEKLY /HU /HR /AP /KL
Notice also that the .XCL file extension is not included when the /Z
switch is used, but is optional when using the /X switch.
A word of warning to those who are going to be using the tag exclusion
files. SETR cannot update those files itself, so when you add new areatags
to your SQUISH.CFG file, be sure to update the tag exclusion files as well.
Failure to do so will result in the wrong echo areas being reported in your
reports. It will also help if you remove any unused areatags from the tag
exclusion files whenever you drop areas from your SQUISH.CFG file, but it
won't hurt your reports if you leave them in, unless you are at the 500
line limit on the tag exclusion file.